Plasma Fast Finality (Plasma FF)
Background
Plasma Finality is a main chain finality plus plasma block time. It is about few minutes.
We make Plasma finality time within 2s.
Bandwidth of fast finality
Operator needs collateral to guarantee fast finality.
The size of collateral should be the amount that a merchant receive per normal confirmation time.
Operator needs collateral for each merchant.
Each Merchant should check that they don't receive tx more than collateral for them.
Fast Finality contract mints special NFT, and it presents the right merchant can use Fast Finality contract.
Fast finality contract
Alice send 1 eth to Bob(merchant).
Alice sign the tx and send to Bob.
The tx has the max block number.
Bob send the tx to operator, and the operator sign the tx and send back to Bob.
We call this tx "FF Tx".
Dispute scenario
First dispute
If double spend happens(or transaction didn't include to block in certain period), Bob can send "FF Tx" with operator's signature to fast finality contract.
This is the assertion that like "Operator promised to include the transaction into block soon, but they didn't"
This assertion is called 'dispute' in Vyper code.
Bob can finalize this assertion after 2 weeks.
Challenge dispute
The operator can challenge showing inclusion-proof of the "FF Tx".
In this case, Bob can exit "FF tx". If Bob can succeeded to exit, there are no problems.
But when Bob's "FF tx" is challenged, Bob can go next step called "second dispute".
Second dispute
In previous section, Bob was challenged by "double spend challenge". It was never invalid history challenge and spent challenge, because Bob has checked coin history before the input of "FF tx". And also Bob never user "FF tx" until he could confirm history before "FF tx".
So, Bob can do "second dispute", showing double spending transaction of "FF Tx".
After this "second dispute" succeeded, Bob can withdraw the amount of "FF tx" from Fast Finality contract.
Contents
Fast Finality Token
Merchants can buy bandwidth as NFT.
If they have NFT, they can dispute.
References
Old documents
Deposit(ETH)
子チェーン内で動くのTX総量(ETH)
手数料 (ETH/min)...(子チェーン内で動くのTX総量) × 0.1%
0.1%というのはクレジットカードの手数料0.2%より仮定
供託(ETH) > 子チェーン内で動くのTX総量(ETH)
問題になってくるのはoperaterの不正な署名(供託された額以上のTXに署名をしwithholdまたは他者への移転)
供託したETHに0~tのindex分けしSMTの時と同様にidを追う
(ex)
Deposit...60,000ETH
子チェーン内で動くのTX総量...600ETH (チャンク分け, 100tps, operaterの供託額の現実感)
0.6(ETH)/min
864(ETH)/day
N party Fast Finality
Sorry! Japanese zone!
何が嬉しいのか
N店舗（もしくはN種類グループ）でfast finalityが使える
信頼できない主体を1とする
内部では信頼できるとしても良い
供託額はdeposit総額ではなく、T(n+1)に最適化できる
また最初はTが少なくても、数日ごとに供託を倍にでき得ることを示す
上記の前提を借ります
前提1
Deposit...60,000ETH
子チェーン内で動くTX総量...600ETH/block
ここから計算できる手数料率が0.1%だと仮定すると、0.6(ETH)/minで、864(ETH)/day
前提2
Fast Finality contractの供託額Fについて
上記で仮定した流量T/blockを使う
Plasma内でn partyがfast finalityの受け取り側になれるとする
店舗A、店舗Bで2 partyなど
この時悪者（送金者兼オペレータ）がdouble spendできる最大数はT(n+1)回
N party+オペレーターだから
F=T(n+1)
解決する方法
fast finalityが使用できるのは、n partyに対してだけ。
自分に対するdouble spendに気をつければ、double spendの回数はT(n+1)回/blockになる
店舗はT=F/(n+1) per block以下になるように送金を受け付け、それ以上はsubmitを待つか、自分の責任で受け付ける。
Fast Finality contract
オペレーターがtxに署名することで、fast finalityを実現
txにはmax block number（このtxが入る最大のブロック番号）をいれなければいけない
もしdouble spendが起きた場合、上記署名とtxを使って、異議申し立て申請ができる
オペレーターはそのtxがblockに含まれていれば、challengeできる
txがblockに含まれていて、かつそのtxがexit可能でなければいけない
invalid historyはおそらくありえない（申し立て者が送信したtxなので、inputが繋がっているかは、申し立て者が確認可能
逆に受取手は、2回目の異議申し立てとしてexit不可なことを示せば、FF contractからお金を手にすることができる
txがexit可能でないことを受取手が示すには、double spendを示せばよい
txがdouble spendであること示すために、以下のtransactionのinclusion proofを提出する
txより古い
同じ入力を使用している
まとめ
最初Fがすごく少ない額でも、T=F/(n+1)の流量ではfast finalityが使用できる。
この時の1日の手数料はT*0.001*60*24=T*1.44
F=T(n+1)
この供託学を稼ぐのにかかる日数はF / (T * 1.44) = (n+1) / 1.44
もし1店舗であれば、F/(1日の手数料)は1.39日
つまり1.39日で手数料によって、供託額を2倍にできる
店舗はフルノードが必要
FF txの入力が正しいことを素早く検証するため
){kind=link}